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METHOD FOR IDENTIFYING UML 
OBJECTS IN A REPOSITORY WITH 
OBJECTS IN XML CONTENT 

CROSS REFERENCE TO RELATED 
APPLICATIONS 

This patent document relates to the following patent 
applications, assigned to the same assignee whereof, which 
are incorporated herein by reference. 

U.S. Pat. No. 6,289,501, issued on Sep. 11, 2001, entitled 
A METHOD AND SYSTEM FOR GENERATING A 
SIMPLE DOCUMENT TYPE DEFINITION FOR 
DATA INTERCHANGE AMONG SOFTWARE 
TOOLS; 

U.S. Pat. No. 6,253,366, issued Jiin. 26, 2001, entitled A 
METHOD AND SYSTEM FOR GENERATING A 
COMPACT DOCUMENT TYPE DEFINITION FOR 
DATA INTERCHANGE AMONG SOFTWARE 
TOOLS; 

U.S. Ser. No. 09/282,230, currently pending filed Mar. 21, 
1999, entitled AMETHOD AND SYSTEM FOR GEN- 
ERATING A HIERARCHIAL DOCUMENT TYPE 
DEFINITION FOR DATA INTERCHANGE AMONG 
SOFTWARE TOOLS; 

U.S. Pat. No. 6,292,932, issued on Sep. 18, 2001, entitled 
A SYSTEM AND METHOD FOR CONVERTING 
FROM ONE MODELING LANGUAGE TO 
ANOTHER; 

U.S. Ser. No. 09/345,289, filed on Jun. 30, 1999, entitled 
A META DATA DRIVEN SYSTEM AND METHOD 
FOR EFFECTING DATA INTERCHANGE AMONG 
SOFTWARE TOOLS IN A DISTRIBUTED ENVI- 
RONMENT; and, 

U.S. Pat, No. 6,330,569, issued on Dec. 11, 2001, entitled 
A METHOD FOR VERSIONING A UML MODEL IN 
A REPOSITORY IN ACCORDANCE WITH AN 
UPDATED XML REPRESENTATION OF THE UML 
MODEL. 

A portion of the disclosure of this patent document 
contains material that is subject to copyright protection. The 
copyright owner has no objection to the facsimile reproduc- 
tion by anyone of the patent disclosure, as it appears in the 
Patent and Trademark OfBce patent files or records, but 
otherwise reserves aU copyright rights whatsoever. 

FIELD OF THE INVENTION 

The present invention generally relates to the field of 
object-oriented programming; and, in particular to a method 
and system for identifying UML objects in a repository with 
objects in XML content. 

BACKGROUND OF THE INVENTION 

XML, the Extensible Markup Language, is a new format 
designed to bring structured information to the Web. It is a 
Web-based language for electronic data interchange. XML is 
an open technology standard of the World Wide Web Con- 
sortium (W3C), which is the standards group responsible for 
maintaining and advancing HTML and other Web-related 
standards. 

XML is a sub -set of SGML that maintains the important 
architectural aspects of contextual separation while remov- 
ing nonessential features. The XML document format 
embeds the content within tags that express the structure. 
XML also provides the ability to express rules for the 
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Structure (i.e., grammar) of a document. These two features 
allow automatic separation of data and metadata, and allow 
generic tools to validate an XML document against its 
grammar. 

While XML is still in its infancy, there are many well- 
documented applications of XML. Example application 
domains include Web commerce, publishing, repositories, 
modeling, databases and data warehouses, services, 
financial, health care, semiconductors, inventory access, and 
more. 

Repositories provide a central place for recording meta- 
data and enable one to store, manage, share and reuse 
information about data (i.e., metadata) that an enterprise 
uses. A repository can store definitional, management and 
operational information. Tools can be integrated with the 
repository to support information sharing and metadata 
reuse, and tool and technology models may be developed to 
manipulate the tool information in the repository. However, 
the transferring of data within models from tool to tool or 
from a tool to the repository has been a cumbersome and 
unyielding task for a long time. 

It is a tedious and time-consuming task to generate a 
format description for enabling the interchange of metadata 
among repositories and each different type of modeling tool 
available. Accordingly, there is a need for automatically 
generating format descriptions to expedite interchange of 
metadata among repositories and modehng tools. As will be 
described hereinbelow, this invention solves this problem by 
automating the production of an XML DTD for meta-models 
stored in a MOF-compliant repository by implementing 
instances of the meta-models expressible in a mcta object 
framework. In the past, entire models would have to be 
replicated to accommodate minor changes. 

SUMMARY OF THE INVENTION 

It is an object of the present invention to provide a method 
for identifying UML objects in a repository with objects in 
XML content. 

Another object of the present invention is to provide a 
method and system that allows modelers the ability to 
identify differences between object models represented in 
different forms. 

Yet another object of the present invention is to provide a 
method and system that allows a user to track changes to 
repository objects made by an external UML editing tool. 

An advantage of the present invention is the software 
language independence of the algorithm used to implement 
the method, making it flexible and portable. 

Another advantage of the present invention is the process 
effectively aUows programs to change existing models. 

These and other objects, which will become apparent as 
the invention is described in detail below, are provided by a 
computer system executing a repository program, wherein a 
method is disclosed for identifying UML objects in the 
repository with objects in an XML file. The method includes 
the steps of parsing the XML file into XML objects and 
building an object tree. Next, the object tree is traversed a 
first time, and for each XML object found that has a name, 
corresponding UML objects are identified. After this, the 
object tree is traversed a second time, and for each XML 
object found that does not have a name, corresponding UML 
objects are then identified through Compositions and Ref- 
erences. The method for traversing said object tree a first 
time includes the steps of identifying a UML object type for 
each XML object, and when the XML object name matches 
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the UML object name at the current level, a UML and XML For example, "make withdrawal" could be defined as an 

object IDs are saved in a * Conversion* object in the memory. operation on a customer account object Properties indicate 

Still other objects, features and advantages of the present ^^^^^ o^'jcc*- Every property of an object has a 

invention will become readUy apparent to those skiUed in property values that define the state of the 
the art from the foUowing detailed description, wherein is 5 object A property can be either an attribute or a reference. 

shown and described only the preferred embodiment of the ^ ^f^^^ ] ^^^^ '^t' the object. 

. 1 , r -1 1 * f *u L i J For example, current account balance could be an attnbute 

mvention, simply by way of illustration of the best mode ^ \ . u- . r™_ • i r 

i\ J c • * *u • A Ml u or the customer account object. The numenc value for the 

contemplated of carrymg out the mvention. As will be , , u...... 

realized, the invention is capable of other and different *=""'°'°f ^ ^''^T f would be stored ir, the customer 
embodiments, and its several details are capable of modifi- 10 ^ffo^nt °bject. A reference is a Imk or pomter to another 

. . * 11 -^u * J object, and implies a relationship to that other object. A 

cations m various obvious respects, all without departing i • . ■ n j u • ^ • j - . j i- . 

from the invention. Accordingly, the drawings and descrip- j^f typically used when it is desired no to duplicate 

tion are to be regarded as iuisttative in nalTre, and not as f,"'"- '""T^^'' ^^^^'T" account object could store 

, . J L . • • * J J * u * * J i_ T the customer s name and address as attnbutes. However, if 

restrictive, and what IS intended to be protected by Letters , j i*- i * *u * > 
„ , , . ' ^, . J J 1 • Tn. * i< the customer opened multiple accounts, the customer s 

Patent is set forth m the appended claims. The present 15 j jj u - / * u- . 

.„ , ^ L * 1 • • name and address would appear in multiple account objects, 

invention will become apparent when taken in conjunction r« r • j • ui x j . . u- ^ 

with the following description and attached drawings. Therefore it is desirable to define a separate custo 

. .,.1 u 7 -J* . 11 ^ JL-Lj and place the name and address as attnbutes of the customer 

wherein like characters mdicate like parts, and which draw- . * . u- * u *u 

P , f,u' 1 object. The customer account object would then contain a 

ings rorm a part oi this application. i ^ ^, ^ , . , 

^ ^ reference to the customer object. 

BRIEF DESCRIPTION OF THE DRAWINGS A normal object program stores objects in a computer 

system's memory. When the program terminates, the 

FIG. 1 is a block diagram of a system that may employ the memory used by those objects is freed and reused by other 

method and system of the present invention. programs, making the objects that the program stored tran- 

FIG. 2 is a software module block diagram of one 25 sient. An object database stores objects in a non-volatile 

embodiment of the method and system of the present memory, such as a computer disk. Since the information on 

invention. a computer disk remains in existence, even when the com- 

FIGS. 3 is an object diagram illustrating the concept of puter is turned off, an object database provides the ability to 

object containment. persistently store objects. An object program that uses an 

FIGS- 4A through 4C combined form a flow chart of the 30 object database thus has the option of storing objects tran- 

overall process of the present invention. ^'^^^^y Persistently. 

FIG. 5 is a flow chart of the overall process for identifying ™g the drawinp and FIG. 1 in particular, a 

aU repository objects corresponding to all XML objects. ^^^^^^ ^^g'™ ^^^^^^ "^^^ ^^^^^^ the method of 

^ ^ a f the present mvention is shown. A server computmg system 

FIGS. 6A and 6B combmed form a flow chart of the 10 is fllustrated with a workstation U (such as Ghent 1) and 

process for identifying the corresponding repository object ^ workstation 12 (such as Client 2) coupled being coupled to 

for each XML object with a name. ^^^^^ H po^jj^g^ jj^at many more workstations 

FIG. 7 is a flow chart of the process for identifying the may also be coupled to the server 10, and a variety of 

corresponding repository object for each XML object with- different networks may be used to for this coupling. The 

out a name. server 10 may also include a storage 13 coupled in a 

FIG. 8 is a flow chart illustrating the process for matching conventional maimer by means of cabling 14. The storage 13 

UML Associations and links without names. may be used for storing data useful to the programs being 

FIG. 9 is a flow chart iUustrating the process for matching ^ the workstations and the server itself. The workstation 

UML AssociationRole objects without names. H may be executing a software modehng tool 1, while the 

FIG. 10 is a flow chart of the process for matching UML workstation 12 may be executing anotiier software modeling 

Generalization objects without names. ^: Moreover, the server 10 is capable of executmg a 

mr- 11 • a u ^ c.u r . l- tt**t repository Software program 15. 

FIG. 11 is a flow chart of the process for matching UML \^ ■ ^ . ^ c 

^ J . ^ ^ The repository program 15 includes tools for cataloging. 

Dependencies without names. . . ^ , ^ ? ^ . i v 

il^^^. „ . ^. , browsing, and managing components that make up an apph- 

HG. 12 IS a flow chart of the process for matching UML ^^^jhods to support these services are disclosed in 

Constraints without names. ^^^^^^j patents and patent applications assigned to the 

FIG. 13 IS a schematic diagram illustrating a partial assignee of this application, including U.S. Pat. No. 5,671, 

storage map in memory of 'Conversion' objects that identify 393 for METHOD FOR COLLAPSING A VERSION TOEE 

and link the XML and repository objects. WHICH DEPICTS A HISTORY OF SYSTEM DATA AND 

DETAILED DESCRIFDON OF ONE " 7L°f^^p™^nn%1?^ 

FMTinDTMFNT METHOD FOR SUPPORTING OBJECT MODEL- 

ING IN A REPOSITORY; U.S. Pat. No. 5,581,755 for 

Before proceeding with a description of the system and METHOD FOR MAINTAINING A HISTORY OF SYS- 

method of the present invention, a summary of Terminology TEM DADV AND PROCESSES FOR AN ENTERPRISE; 
used herein is provided, which may be helpful in under- 60 U.S. Pat. No. 5,557,793 for IN AN OBJECT ORIENTED 

standing the disclosed embodiment. REPOSITORY, A METHOD FOR TREAHNG A GROUP 

An object is an abstract representation of a real-world OF OBJECTS AS A SINGLE OBJECT DURING EXECU- 

concept or thing. For example, an object can be used to TION OF AN OPERATION; pending application Ser. No. 

represent a customer account in a banking application. An 08/623,490, filed on Mar. 28, 1996, for A METHOD FOR 
object has features, which can be either an operation or a 65 MAPPING TYPES IN A MODEL IN A OBJECT- 

property. An operation defines an action that an object can ORIENTED REPOSITORY TO LANGUAGE CON- 

perform, or an action that can be performed on the object. STRUCTS FOR A C BINDING FOR THE REPOSITORY; 



09/02/2004, EAST Version: 1.4.1 



us 6,408,311 Bl 

5 6 

U.S. Pat. No. 5,721,925, for METHOD FOR GENERI- Referring now to FIG. 4B at the connector A, an inquiry 

CALLYI>fVOKING OPERAnONS IN AN OBJECT ORI- is made as to whether or not the XML object has a name 

ENTED REPOSITORY; U.S. Pat. No. 6,366,251, issued on (diamond 37). If the answer to this inquiry is yes, then 

Apr. 24, 2000, for A METHOD FOR GENERATING OLE another inquiry is made as to whether or not the repository 

AUTOMAnON AND IDL INTERFACES FROM META- s object has a name (diamond 38). If the answer to this second 

DATA INFORMATION; U.S. Pat. No. 5,765,039 for A inquiry is yes, then a third inquiry is made as to whether or 

METHOD FOR PROVIDING OBJECT DATABASE not the XML object name and the repository object name 

INDEPENDENCE IN A PROGRAM WRITTEN USING match (diamond 39). If the answer to this inquiry is yes, then 

THE C++ PROGRAMING LANGUAGE; U.S. Pat, No. the object is found (block 40). On the other hand, if the 

5,758,348, for A METHOD FOR GENERICALLY names do not match or if the repository object does not have 

MANIPULAHNG PROPERTIES OF OBJECTS IN AN a name, the repository object name is changed to the XML 

OBJECT ORIENTED REPOSITORY; U.S. Pat. No. 5,701, object name (block 41). 

472, for A METHOD FOR LOCAHNG A VERSIONED if the XML object does not have a name, no leg from the 

OBJECT WITHIN A VERSION TREE DEPICTING A diamond 37, then still another inquiry is made as to whether 

HISTORY OF SYSTEM DATA AND PROCESSES FOR or not the repository object has a name (diamond 42). If the 

answer to this inquiry is yes, then the repository object name 

Ss?S^?3ITcTrO^^^^^^^ objectdoesnothaveaname;orup^^^^^^ 

REMOTELY WITH AN OBJECT-ORIENTED ^^^'^^^^ ^7 Hi'r^'ir ? ^ k ^hi^tration 

REPOSITORY, each of which are hereby incorporated by 20 ^^^^"^^^ ^ ^ connector B. 

reference as if set forth in fuU herein. Referring now to ¥IG. 4C at the connector B, all reposi- 

Referring now to FIG. 2, a block diagram illustrates ^^^y objects conesponding to all the XML objects are 

various software modules being executed by the server 10 identified (block 44). The details of this step are amplified m 

and the software tools 1 and 2 being executed by the FIG- 5 and described further hcrcinbelow. Next, the differ- 

workstations 11 and 12, respectively. In the disclosed 25 ^^^^^ between the XML objects and the repository objects 

embodiment the software tool 1 running in the Qient 1 are identified (block 45); and, the repository objects are 

interfaces directly with a dll program 20, which is a software updated to match the XML objects block 46 and the process 

program used for loading UML models into the repository ends (bubble 47). The details of the parts of the process 

from an XML file. The dll program 20 interfaces directly depicted by the blocks 45 and 46 are described in further 

with the repository 15, which has stored therein an exem- detail in the U.S. Pat. No. 6,330,569, issued on Dec. 11, 

plary software model 21. The software 2 running in the 2001. 

Ghent 2 interfaces directly with an XML file 22 residing on Referring now to FIG. 5, the process for identifying aU the 

the server 10. A parser 23 is disposed between the dll repository objects corresponding to all the XML objects is 

program 20 and the XMLfile 22 for parsmg the data stremi ^1^^^^^ ^^^^ ^^^^ ^ ^^^^ ^^^^^^ 50 followed 

bemg received from the Qient 2 and transmitted back to the ^ ^ traversing the XML object tree; and, for each 

Ghent 2^ THe parser 23 is a collection of objects, which is a ^^^^^ ^^^^ ^ ^^^^ identifying the corre- 

result of parsmg the data stream. . . , , 1 ci\ Tn.- r 

^ ^ . ^ r.T^ ^ i_' .J- Ml . sponding repository object (block 51). This part or the 

Refernne now to FIG. 3, an obiect diagram illustrating the ^ ^ i c j • nr-c \i ctj ^ n u 

, . . , , . , u Tir*u' vxiff process is amphfied in FIGS. 6A and 6B and will be 

concept of obiect containment is shown. Within XML, a ^ . ^ . • xt *l v*^t u- * . 

parent object X has three illustrated owned objects XI, X2 ^^^^"^^^ fiirther heremafter. Next, the XML object tree is 

and X3, wherein owned object XI owns object Xll and 40 agam traversed; however, in this part of the process it is 

object X2 owns object X21. After the XML file is parsed the traversed repeatedly for each of the steps depicted m FIG. 7. 

objects pC, XI, X2, X3, Xll and X21) are represented as a For each XML object found dumg a traversal that does not 

DOM ("Doument Object Model") object tree, as shown in l^ave a name, the corresponding repository object is identi- 

FIG. 3. The term "level" as used herein refers to all those fied through Compositions and References (block 52). This 

objects at the same ownership from an owning object. For 45 P^n of the process is amplified in FIG. 7 and will be 

example, objects XI, X2 and X3 are all on the same level; described further hereinafter. After this, the process ends 

and, the owned objects Xll and X21 are on the same level. (bubble 53). 

The term "depth*' refers within a single branch from the root Referring now to FIG. 6A, the first of a two-sheet iUus- 

object (e.g., object X or Y) to each owned object. For tration is shown of the process for identifying repository 

example, traversing from X, to XI to Xll is a depth-first 50 objects that correspond to each XML object found that has 

traversal of the objects. a name. The process begins with a start bubble 55 followed 

On the repository side of the diagram, the same concepts by a step of identifying the UML object type for this object 

apply to the object Y, owned objects Yl, Y2 and Y3, as well XML object; i.e., the current XML object under analysis 

as the owned object Y31. (block 56). After this, an inquiry is made as to whether or not 

Referring now to FIG. 4A, the first of a three -sheet flow 55 a name is mandatory for this type (diamond 57). If the 

chart of the overall process is shown. The process begins answer to this inquiry is yes, then another inquiry is made as 

with a start bubble 30 followed by a step of receiving a to whether or not the XML object has a name (diamond 58). 

user's identification of a repository package from where If the answer to this latter inquiry is no, then an error 

XML data wUl be loaded (block 31). Next, the dll program message is recorded (bubble 59). On the other hand if a 

20 is called with the repository object ID and name of the 60 name is not mandatory for this type, then still another 

XML file (block 32). After this, the dll program 20 will parse mquiry is made as to whether or not the XML object has a 

the XML file using the parser 23 (block 33). The parser then name (diamond 60). If the answer to this inquiry is no, then 

builds the DOM object tree (block 34). Following this, the the process ends (bubble 61). On the other hand, if the XML 

root object is read from the XML file (block 35) and the root object does have a name, then the process illustration 

object is read from the repository (block 36). The process 65 continues in FIG. 6B as depicted by a connector C. 

illustration continues in FIG. 4B as denoted by a connector Referring now to FIG. 6B at the connector C, an inquiry 

A. is made as to whether or not the XML name matches any 
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repository object name at the current level (diamond 62). If 
the answer to this inquiry is yes, then the repository object 
ID and the XML object are saved in memory in an object 
named 'Conversion' (block 63). After this the process ends 
(bubble 64). Retuming back to the diamond 62, if the XML 5 
name docs not match any repository object name at the 
current level, then the XML object ID is saved in the 
* Conversion* object in memory (block 65). Next, the 'Con- 
version* object is marked as needing a new repository object 
(block 66). This means that a new repository object is to be 10 
created. After this, the process ends (bubble 67). 

Referring now to FIG. 7, the process for identifying the 
corresponding repository object for each XML object with- 
out a name is shown. The process begins with a start bubble 
70 followed by a step of matching UML Association and 15 
Link objects without names (block 71). The details of the 
step of the process are amplified in FIG, H and described 
further hereinafter. Next, the UML AssociationRole objects 
without names are matched (block 72). The details of the 
step of the process are amplified in FIG, 9 and described '^^ 
further hereinafter. After this, the UML Generalization 
objects without names are matched (block 73). The details of 
the step of the process are amplified in FIG. 10 and described 
further hereinafter. 

Following the above, the UML Dependency objects with- 
out names are matched (block 74). The details of the step of 
the process are amplified in FIG. U and described further 
hereinafter. The UML Constraint objects without names are 
thereafter matched (block 75), The details of the step of the 
process are amplified in FIG. 12 and described further 
hereinafter. The process then ends (bubble 76). 

Referring now to FIG, 8, the process for matching Asso- 
ciations and Links without names is shown. The process 
begins with a start bubble 80, followed by a step of retriev- 
ing AssociationEnds from the XML file for the current 
Association object (block 81). Next, an inquiry is made as to 
whether or not all AssociationEnds have names (diamond 
82). If the answer to this inquiry is yes, then for each 
Association found in the repository at the current level, the 
names of the AssociationEnds are compared with the Asso- 
ciationEnd names in the XML file (block 83). After this, 
another inquiry is made as to whether or not all the Asso- 
ciationEnd names match (diamond 84). If the answer to this 
inquiry is yes, then a branch is made back to a connector E 
of FIG. 6B for saving the repository object and the XML 
object ID'S in the 'Conversion' object in memory (bubble 
85). On the other hand, if the answer to this inquiry is no, 
then a branch is made back to a connector F in FIG. 6B for 
saving the XML object ID in the 'Conversion' object in 
memory. 

Returning back to the decision diamond 82, if all of the 
AssociationEnds do not have names, then the repository 
object ID of the AssociationEnd types of the Association- 
Ends is retrieved from the 'Conversion' object (block 87). 55 
Ne5£t, for each Association found in the repository at the 
current level, compare the object ID's of the AssociationEnd 
types with the repository object ID's retrieved in the previ- 
ous step (block 88). Following this, another inquiry is made 
as to whether or not all the repository object ID's match gQ 
(diamond 89). If the answer to this inquiry is yes, then a 
branch is made back to FIG. 6B at the connector E (bubble 
90). On the other hand, if all of the repository object ID's do 
not match, then a branch is made back to the connector F in 
FIG. 63. 65 

Referring now to FIG. 9, the process for matching UML 
AssociationRole objects without names is shown. The pro- 
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cess begins with a start bubble 95 followed by a step of 
retrieving 'Base' Reference object from the XML file; and, 
the repository object ID for this object is obtained (block 
96). Next, for each AssociationRole object in the repository 
at the current level, the repository object ID of the 'Base' 
Reference is matched to the repository object ID retrieved in 
the previous step (block 97). Following this, an inquiry is 
made as to whether or not any of the repository object ID's 
match (diamond 98). If the answer to this inquiry is yes, then 
a branch is made to the connector E in FIG. 6B. On the other 
hand, if the answer to this inquiry is no, then a branch is 
made to the connector F in FIG. 6B. 

Referring now to FIG. 10, the process for matching UML 
Generalization objects without names is shown. The process 
begins with a start bubble 103 followed by a step of 
retrieving the repository object ID of the XML sub-type 
object (block 104). Next, an inquiry is made as to whether 
or not the XML sub -type object ID matches any sub-type 
object ID of the current set of repository generalization 
objects (diamond 105). If the answer to this inquiry is yes, 
then the repository object ID of the XML super-type object 
is retrieved (block 106). Next, another inquiry is made as to 
whether or not the XML super-type object ID matches any 
sub -type object ID of the current set of repository generali- 
zation objects (diamond 107). If the answer to this inquiry 
is yes, then a branch is made to the connector E in FIG. 6B. 
On the other hand, if the answer to this inquiry is no, or if 
the answer to the inquiry depicted by the diamond 105 is no, 
then a branch made to the connector F in FIG. 6B (bubbles 
109 and 110). 

Referring now to FIG. 11, the process for matching UML 
Dependencies without names is shown. The process begins 
with a start bubble 112 followed by a step of retrieving client 
Reference objects from the XML file (block 113). Next, an 
inquiry is made as to whether or not all the chcnt XML 
objects have matching repository objects (diamond 114). If 
the answer to this inquiry is no, then a branch is made to the 
connector F in FIG. 6B. (bubble 115). On the other hand, if 
the answer to this inquiry is yes, then the supplier Reference 
objects are retrieved from the XML file (block 116). After 
this, another inquiry is made as to whether or not all these 
suppUer XML objects have matching repository objects 
(diamond 117). If the answer to this inquiry is no, then a 
branch is made to the connector F in FIG. 6B. 

On the other hand, if the answer to the inquiry depicted by 
the diamond 1L7 is yes, then the repository object ID's for 
the client and supplier XML objects are retrieved from the 
* Conversion' object (block 119). Next, for each Dependency 
in the repository at the current level, the client and supplier 
repository object ID's are matched with those retrieved in 
the previous step (block 120). Following the above, still 
another inquiry is made as to whether or not all repository 
object ID's match (diamond 121). If the answer to this 
inquiry is yes, then a branch is made to the connector E in 
FIG. 6B (bubble 122). On the other hand, if the answer to 
this latter inquiry is no, then a branch is made to the 
connector F in FIG. 6B (bubble 123). 

Referring now to FIG. 12, the process for matching UML 
ConsUaints without names is shown. The process begins 
with a start bubble 125 followed by a step of retrieving a list 
of ConstrainedElements from the XML file (block 126). 
Next, an inquiry is made as to whether or not all of these 
XML objects have matching repository objects (diamond 
127). If the answer to this inquiry is no, then a branch is 
made to the connector F in FIG. 6B (bubble 128). On the 
other hand, if the answer to this inquiry is yes, then the 
repository object ID's for all of the XML objects is retrieved 



09/02/2004, EAST Version: 1.4.1 



us 6,4( 

9 

from the ^Conversion' object (block 129). After this, for each 
Constraint at the current level, a match is made of all of its 
ConstrainedElcment repository object ID's with the reposi- 
tory object ID'S form the previous step (block 130). Another 
inquiry is then made as to whether or not all of the repository 
object ID'S match (diamond 131). If the answer to this 
inquiry is yes, then a branch is made to the connector E in 
FIG. 6B (bubble 132). On the other hand, if the answer to 
this inquiry is no, then a branch is made to the connector F 
in the FIG. 6B (bubble 133). 

Referring now to FIG. 13, a schematic diagram illtistrat- 
ing a partial storage map in memory of 'Conversion' objects 
that identify and link the XML and repository objects is 
shown. A repository model 135 is made up of a package 136, 
which may typically comprise classes 137, 138 and 139, In 
a similar manner, an XML model 140 is made up of a 
package 141, which may typically comprise classes 142, 143 
and 144. Following completion of the process described 
hereinabove, * Conversion' object 145 includes the reposi- 
tory ID for the class 137 and the XMI ID for the class 142. 
Similarly, a ' Conversion' object 148 includes a repository ID 
149 for the class 139 and an XMI ID for the class 144. Every 
object in the XML file will have a corresponding * Conver- 
sion* object and those 'Conversion' objects will either have 
a repository ID that identifies the corresponding repository 
object, or in the case where there is no corresponding 
object— NEW OBJECT will be set to TRUE. 

The methods and apparatus of the present invention, or 
certain aspects or portions thereof, may take the form of 
program code (i.e., instructions) embodied in tangible 
media, such as floppy diskettes, CD-ROMS, hard drives, or 
any other machine-readable storage medium, wherein, when 
the program code is loaded into and executed by a machine, 
such as a computer, the machine becomes an apparatus for 
practicing the invention. The methods and apparatus of the 
present invention may also be embodied in the form of 
program code that is transmitted over some transmission 
medium, such as over electrical wiring or cabling, through 
fiber optics, or via any other form of transmission, wherein, 
when the program code is received and loaded into and 
executed by a machine, such as a computer, the machine 
becomes an apparatus for practicing the invention. When 
implemented on a general-purpose processor, the program 
code combines with the processor to provide a unique 
apparatus that operates analogously to specific logic circuits. 

Although the invention has been described with reference 
to a specific embodiment, this description is not meant to be 
construed in a limiting sense. Various modifications of the 
disclosed embodiment as well as alternative embodiments of 
the invention will become apparent to one skilled in the art 
upon reference to the description of the invention. It is 
therefore contemplated that the appended claims will cover 
any such modifications of embodiments that fall within the 
true scope of the invention. 

What is claimed is: 

1. In a computer system executing a repository program 
and having a memory, a method for identifying UML 
(Unified Modeling Language) objects in said repository with 
objects in an XML (Extensible Markup Language) file, said 
method comprising the steps of: 

a. parsing said XML file into XML objects and building 
an object tree; 

b. traversing said object tree a first time, and for each 
XML object found that has a name, identifying corre- 
sponding UML objects; 

c. traversing said object tree a second time, and for each 
XML object found that does not have a name, identi- 
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fying corresponding UML objects through composi- 
tions and references; and 

d. saving 'Conversion* objects in said memory indicative 
of the results of said parsing and traversing. 

5 2. The method as in claim 1, wherein said step of parsing 
further includes: 

e. reading root XML object from said object tree; 

f. reading root UML object from said repository. 

3. The method as in claim 2, further including the steps of: 
10 g. determining if said root XML object has a name, and 

if so; 

h. determining if traversal of said object tree is complete, 
and if not; 

i. repeating all of the steps above until said traversal is 
15 complete. 

4. The method as in claim 3, wherein said root XML 
object does not have a name and said root UML object does 
have a name, further including the step of removing the 
name from said UML object. 

5. The method as in claim 3, wherein said XML root 
object has a name and said UML object does not have a 
name, further including the step of changing said UML 
object name to the same as said XML root object name. 

6. The method as in claim 3, wherein said XML root 
object has a name and said UML object also has a name, 
further including the step of determining if said UL object 
name is the same as said XML root object name. 

7. The method as in claim 6, wherein said XML root 
object name is not the same as said UML object, further 
including the step of changing said UML object name to the 

30 same as said XML root object name. 

8. The method as in claim 1, wherein said step of 
traversing said object tree a first time includes the steps of: 

a. identifying said UML object type for each XML object; 

b. when said XML object name matches said UML object 
35 name at current level, saving an object ID for said UML 

object and an object ID for said XML object in a 
* Conversion' object in said memory. 

9. The method as in claim 8, wherein if said XML object 
name does not match said UML object at current level, 

40 saving said XML object ID in a * Conversion' object in said 
memory and marking the ' Conversion' object as needing a 
new UML object. 

10. The method as in claim 1, wherein said root XML 
object does not have a name and said root UML object does 

45 not have a name, further including the step of matching said 
UML Association and Link objects without names by match- 
ing the names and types of their connections. 

11. The method as in claim 1, wherein said step of 
traversing said object tree a second time further includes the 

50 step of matching UML Association Role objects without 
names by matching the base Association for the Association 
Role. 

12. The method as in claim 1, wherein said step of 
traversing said object tree a second time further comprises 

55 the step of matching UML Generalization objects without 
names by matching the sub-type and super-type of each 
UML Generalization object. 

13. The method as in claim 1, wherein said step of 
traversing said object tree a second time further includes the 

60 step of matching UML Dependency objects vnthout names 
by matching the client and supplier of each UML Depen- 
dency object. 

14. The method as in claim 1, wherein said step of 
traversing said object tree a second time further includes the 

65 step of matching UML Constraint objects without names by 
matching the Constrained Elements of each UML Constraint 
object. 
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15. A storage medium encoded with machine-readable 
computer program code for identifying UML object in a 
repository with objects in an XML file, wherein, when the 
computer program code is executed by a computer, the 
computer performs the steps of: 

a. parsing said XML file into XML objects and building 
an object tree; 

b. traversing said object tree a first time, and for each 
XML object found that has a name, identifying corre- 
sponding UML objects; and, 

c. traversing said object tree a second time, and for each 
XML object found that does not have a name, identi- 
fying corresponding UML objects through composi- 
tions and references; and 

d. saving * Conversion' objects in said memory indicative 
of the results of said parsing and traversing, 

16. The storage medium as in claim 15, wherein said step 
of parsing further includes: 

e. reading root XML object from said object tree; 

f. reading root UML object from said repository. 

17. The storage medium as in claim 16, further including 
the steps of: 

g. determining if said root XML object has a name, and 
if so; 

h. determining if traversal of said object tree is complete, 
and if not; 

i. repeating all of the steps above until said traversal is 
complete. 

18. The storage medium as in claim 17, wherein said root 
XML object does not have a name and said root UML object 
does have a name, further including the step of removing the 
name from said UML object. 

19. The storage medium as in claim 17, wherein said XL 
root object has a name and said UML object does not have 
a name, further including the step of changing said UML 
object name to the same as said XML root object name. 

20. The storage medium as in claim 17, wherein said 
XML root object has a name and said UML object also has 
a name, farther including the step of determining if said 
UML object name is the same as said XML root object 
name. 
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21. The storage medium as in claim 20, wherein said 
XML root object name is not the same as said UML object, 
further including the step of changing said UML object 
name to the same as said XML root object name. 

22. The storage medium as in claim 15, wherein said step 
of traversing said object tree a first time further includes the 
steps of: 

a. identifying said UML object type for each XML object; 

b. when said XML object name matches said UML object 
name at current level, saving an object ID for said UML 
object and an object ID for said XML object in a 
'Conversion' object in said memory. 

23. The storage medium as in claim 22, wherein said 
XML object name does not match said UL object at current 
level, saving said XML object ID in a * Conversion* object in 
said memory and marking the 'Conversion' object as need- 
ing a new UML object. 

24. The storage medium as in claim 15, wherein said root 
XML object does not have a name and said root UML object 
does not have a name, further including the step of matching 
said UML Association and Link objects without names. 

25. The storage medium as in claim 15, wherein said step 
of traversing said object tree a second time further includes 
the step of matching UML AssociatioQ Role objects without 
names by matching the base Association for the Association 
Role. 

26. The storage medium as in claim 15, wherein said step 
traversing said object tree a second time further comprises 
the step of matching UML Generalization objects without 
names by matching the sub-type and super-type of each 
UML Generalization. 

27. The storage medium as in claim 15, wherein said step 
of traversing said object tree a second tie further includes the 
step of matching UML Dependency objects without names 
by matching the client an supplier of each UML Dependency 
object. 

28. The storage medium as in claim 15, wherein said step 
of traversing said object tree a second time further includes 
the step of matching UML Constraint objects without names 
by matchiag the Constrained Elements of each UML Con- 
straint object. 
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